I tried to play around with a few of the parameters, like current levels etc, but it does not seem to make a difference.

My next step is to add linear glass scales to both axes, so maybe the problem will take care of itself there. But I see a number of options and don't understand the tradeoffs.

Option 1:

Add the linear scale to the stepper and configure in KFLOP as closed loop stepper

Option 2:

Add the linear scale to the stepper and configure in KFLOP as 4 phase servo.

Option 3:

Add encoder to stepper. Configure this as closed loop stepper. Add linear scale as outer feedback loop

Option 4:

Add encoder to stepper. Configure this as 4 phase servo. Add linear scale as outer feedback loop.

Obviously, I would like to avoid the dual-feedback configurations because of the extra cabling involved.

Any advise would be greatly appreciated!

What drives are you using?  What is your configuration?

Steppers vibrating would not be normal.  You might perform Step Response Plots of 0 size to see what is happening.

Regards

TK

 

Ok, I have my lathe up and running. So far so good.

Of the two steppers, one makes a lot of high pitch noise when not moving. But both steppers vibrate noticeably when I touch the shafts.

Is that expected behavior? What I can I do about it?

I tried to play around with a few of the parameters, like current levels etc, but it does not seem to make a difference.

My next step is to add linear glass scales to both axes, so maybe the problem will take care of itself there. But I see a number of options and don't understand the tradeoffs.

Option 1:

Add the linear scale to the stepper and configure in KFLOP as closed loop stepper

Option 2:

Add the linear scale to the stepper and configure in KFLOP as 4 phase servo.

Option 3:

Add encoder to stepper. Configure this as closed loop stepper. Add linear scale as outer feedback loop

Option 4:

Add encoder to stepper. Configure this as 4 phase servo. Add linear scale as outer feedback loop.

Obviously, I would like to avoid the dual-feedback configurations because of the extra cabling involved.

Any advise would be greatly appreciated!

 

 

With no encoder in the system right now, the step response screen can't measure anything, right?

I am using a SnapAMP with the following configuration:

void main() 
{
     
    WriteSnapAmp(SNAP0+SNAP_PEAK_CUR_LIMIT0,9);  // current limit
    WriteSnapAmp(SNAP0+SNAP_PEAK_CUR_LIMIT1,9);  // current limit
    Delay_sec(0.1);  // wait for any fault to clear
        
        
    ch4->InputMode=NO_INPUT_MODE;
    ch4->OutputMode=MICROSTEP_MODE;
    ch4->Vel=200.000000;
    ch4->Accel=5000.000000;
    ch4->Jerk=50000.000000;
    ch4->P=1.000000;
    ch4->I=0.000000;
    ch4->D=0.000000;
    ch4->FFAccel=0.000000;
    ch4->FFVel=0.000000;
    ch4->MaxI=200.000000;
    ch4->MaxErr=1000000.000000;
    ch4->MaxOutput=200.000000;
    ch4->DeadBandGain=1.000000;
    ch4->DeadBandRange=0.000000;
    ch4->InputChan0=4;
    ch4->InputChan1=4;
    ch4->OutputChan0=8;
    ch4->OutputChan1=9;
    ch4->LimitSwitchOptions=0x0;
    ch4->InputGain0=1.000000;
    ch4->InputGain1=1.000000;
    ch4->InputOffset0=0.000000;
    ch4->InputOffset1=0.000000;
    ch4->invDistPerCycle=1.000000;
    ch4->Lead=0.000000;
    ch4->MaxFollowingError=1000000000.000000;
    ch4->StepperAmplitude=40.000000;
    
    
    ch4->iir[0].B0=1.000000;
    ch4->iir[0].B1=0.000000;
    ch4->iir[0].B2=0.000000;
    ch4->iir[0].A1=0.000000;
    ch4->iir[0].A2=0.000000;
 
    ch4->iir[1].B0=1.000000;
    ch4->iir[1].B1=0.000000;
    ch4->iir[1].B2=0.000000;
    ch4->iir[1].A1=0.000000;
    ch4->iir[1].A2=0.000000;
 
    ch4->iir[2].B0=1.000000;
    ch4->iir[2].B1=0.000000;
    ch4->iir[2].B2=0.000000;
    ch4->iir[2].A1=0.000000;
    ch4->iir[2].A2=0.000000;
     
     
    ch5->InputMode=NO_INPUT_MODE;
    ch5->OutputMode=MICROSTEP_MODE;
    ch5->Vel=200.000000;
    ch5->Accel=5000.000000;
    ch5->Jerk=50000.000000;
    ch5->P=1.000000;
    ch5->I=0.000000;
    ch5->D=0.000000;
    ch5->FFAccel=0.000000;
    ch5->FFVel=0.000000;
    ch5->MaxI=200.000000;
    ch5->MaxErr=1000000.000000;
    ch5->MaxOutput=200.000000;
    ch5->DeadBandGain=1.000000;
    ch5->DeadBandRange=0.000000;
    ch5->InputChan0=5;
    ch5->InputChan1=5;
    ch5->OutputChan0=10;
    ch5->OutputChan1=11;
    ch5->LimitSwitchOptions=0x0;
    ch5->InputGain0=1.000000;
    ch5->InputGain1=1.000000;
    ch5->InputOffset0=0.000000;
    ch5->InputOffset1=0.000000;
    ch5->invDistPerCycle=1.000000;
    ch5->Lead=0.000000;
    ch5->MaxFollowingError=1000000000.000000;
    ch5->StepperAmplitude=60.000000;
 
    ch5->iir[0].B0=1.000000;
    ch5->iir[0].B1=0.000000;
    ch5->iir[0].B2=0.000000;
    ch5->iir[0].A1=0.000000;
    ch5->iir[0].A2=0.000000;
 
    ch5->iir[1].B0=1.000000;
    ch5->iir[1].B1=0.000000;
    ch5->iir[1].B2=0.000000;
    ch5->iir[1].A1=0.000000;
    ch5->iir[1].A2=0.000000;
 
    ch5->iir[2].B0=1.000000;
    ch5->iir[2].B1=0.000000;
    ch5->iir[2].B2=0.000000;
    ch5->iir[2].A1=0.000000;
    ch5->iir[2].A2=0.000000;
     
     
    DefineCoordSystem(4,5,-1,-1); //define ch4 as x and ch5 as y; z and a disabled
     
    EnableAxis(4);
    EnableAxis(5);
}

---In DynoMotion@yahoogroups.com, <tk@...> wrote :

What drives are you using?  What is your configuration?

Steppers vibrating would not be normal.  You might perform Step Response Plots of 0 size to see what is happening.

Regards

TK

On 10/6/2016 3:39 AM, homeloan@... [DynoMotion] wrote:

 

Ok, I have my lathe up and running. So far so good.

Of the two steppers, one makes a lot of high pitch noise when not moving. But both steppers vibrate noticeably when I touch the shafts.

Is that expected behavior? What I can I do about it?

I tried to play around with a few of the parameters, like current levels etc, but it does not seem to make a difference.

My next step is to add linear glass scales to both axes, so maybe the problem will take care of itself there. But I see a number of options and don't understand the tradeoffs.

Option 1:

Add the linear scale to the stepper and configure in KFLOP as closed loop stepper

Option 2:

Add the linear scale to the stepper and configure in KFLOP as 4 phase servo.

Option 3:

Add encoder to stepper. Configure this as closed loop stepper. Add linear scale as outer feedback loop

Option 4:

Add encoder to stepper. Configure this as 4 phase servo. Add linear scale as outer feedback loop.

Obviously, I would like to avoid the dual-feedback configurations because of the extra cabling involved.

Any advise would be greatly appreciated!

 

step response-13779(1).png

You forgot to select to Plot Current.  Better yet save and attach the data so we can replot it however we wish.

Regards

TK

 

Ah. I see.

I am attaching it

step response-13781.txt
step response-13781(1).png

The plot shows about 200ma p-p current variation.  I suppose that may be the "hiss".  Sometimes the "hiss" can be influenced by the motor cables if they are too close together and cross talk.  Or the shields couple noise from one to the other.  It may not be possible to totally eliminate it.

Was the plot made with the motors "vibrating" or not?  Hissing?

Regarding touchpad:  SnapAmp does generate a lot of noise as the many outputs are all switching 80V with fast rise/fall times for efficiency.

It might make sense to add an earth ground to Snapamp DC GND if you don't already have an Earth GND.

You may need to use a USB Isolator.  See this post and/or search the forum for Olimex.

https://groups.yahoo.com/neo/groups/DynoMotion/conversations/messages/4303

Disabling commands 0V but still switches.  That is why the "hiss" goes away.

 

Ah. I replotted with current enabled and also attached the raw data.

One more thing I noticed, and may or may not be relevant:

I am running KMotion on a laptop. It is running on battery. There are some interactions between the KFlop and the trackpad.

- The tackpad is working great when the KFlop is not connected.
- After connecting KFlop, the tackpad initially still works great
- After running the program I attached earlier, the trackpad is unusable. The pointer jumps wildly around the finger position
- disabling the axes using the checkbox in KMotion stops the motor and the hiss, of course, but the tackpad is still unusable until I unplug the USB cable.

Strange that the "vibration" would show up in the motor current plots as a form of oscillation.

Normally Steppers sit fairly still when idle.  You might reduce the current Amplitude when idle to see if that helps. 

You might make another plot with the "hiss" now removed.

Can you describe the "vibration"?  How do you know it is less than a motor step?  What is your definition of a motor step?

Do you have an encoder that you could attach so we could observe the actual motion?

Regards

TK

 

Small update:

Connecting Kflop Ground to Case ground took care of the trackpad problem, but otherwise there was no change.

I took another stepper motor (motor3) of same size as motor1 but of different manufacture. This motor, I connected to the SnapAMP directly, disconnecting the wiring to motor1 and motor2. It acts like motor2, in that it does not hiss, but only vibrates. So I can replace motor1 to take care of the hiss.

That still leaves me with the vibration both motor2 and 3 display. This vibration is less than a step size in amplitude. Is any vibration normal? How much?

---In DynoMotion@yahoogroups.com, <homeloan@...> wrote :

The plot was made with only one motor (motor1) enabled. It is hissing and vibrating. I see no difference if I disconnect the other motor (motor2) entirely.

The motor2 "only" vibrates. When I put my ear close, I can hear the same hiss as with motor1, even with motor1 disabled and disconnected.

I can live with a hiss, if I have to, but the shaft vibration causes me a lot of concern...

I was thinking about getting that USB isolator already, but the loss of the trackpad is not objectionable to me right now. I just thought it might help diagnosing the problem.

---In DynoMotion@yahoogroups.com, <tk@...> wrote :

The plot shows about 200ma p-p current variation.  I suppose that may be the "hiss".  Sometimes the "hiss" can be influenced by the motor cables if they are too close together and cross talk.  Or the shields couple noise from one to the other.  It may not be possible to totally eliminate it.

Was the plot made with the motors "vibrating" or not?  Hissing?

Regarding touchpad:  SnapAmp does generate a lot of noise as the many outputs are all switching 80V with fast rise/fall times for efficiency.

It might make sense to add an earth ground to Snapamp DC GND if you don't already have an Earth GND.

You may need to use a USB Isolator.  See this post and/or search the forum for Olimex.

https://groups.yahoo.com/neo/groups/DynoMotion/conversations/messages/4303

Disabling commands 0V but still switches.  That is why the "hiss" goes away.

Regards
TK

On 10/6/2016 11:52 PM, homeloan@... [DynoMotion] wrote:

 

Ah. I replotted with current enabled and also attached the raw data.

One more thing I noticed, and may or may not be relevant:

I am running KMotion on a laptop. It is running on battery. There are some interactions between the KFlop and the trackpad.

- The tackpad is working great when the KFlop is not connected.
- After connecting KFlop, the tackpad initially still works great
- After running the program I attached earlier, the trackpad is unusable. The pointer jumps wildly around the finger position
- disabling the axes using the checkbox in KMotion stops the motor and the hiss, of course, but the tackpad is still unusable until I unplug the USB cable.

step response-13786(1).txt
step response-13786(1).png

I think you are at the noise level of SnapAmp.  SnapAmp has a 70Amp current measurement range so to control within 100ma quickly is difficult with high-frequency high-voltage switching going on.

Actually SnapAmp doesn't do "chopping".  Instead it controls PWM (Voltage) based on measured and desired currents with a digital current feedback loop.  How the system dynamically reacts to current errors depends on the supply voltage, motor parameters (Inductance), and internal gains.   Reducing the Supply Voltage will essentially reduce the feedback gain.  If the error response is slow the effect of measurement noise will be reduced.  SnapAmp has programmable Gains that may make a difference at the expense of performance.

What makes you think this is a problem?

Regards

TK

 

Update:

I suspected the power supply perhaps causing the problem, so I replaced it with Lab Power supply.
I can now say that the vibration is directly proportional to the supply voltage.The lab power supply can only do 31V, so that was my starting point. There, the vibration is still very noticeable. By the time I cut down the supply voltage down to 5V, the vibration is barely there.

The lab power supply did show about 0.5A at that point, even though the stepper was set to and consumed 1A, so it is not like we are simply fully open, the chopping is still going on.

Is it simply in the nature of the system that a higher supply voltage causes larger idle vibrations? Or am I doing something wrong?

Driving a Stepper as a 4 Phase Brushless motor is not common and is somewhat complicated.  it is basically as complex as a 3 Phase Brushless motor as Commutation and Tuning are required.  The commutation is more critical as there are many times more motor poles.  Tuning is more difficult as there is usually more torque ripple, cogging, inductance, etc... than with a servo motor.  The result is usually better than a Stepper Drive but not as good as a Servo.  So I usually recommend going to a servo motor if your goal is for performance.

But if you want to try it we can help.  It would be great to document on the wiki the performance you get driving as a Stepper compared with driving as a Servo.

If anything is configured wrong (ie commutation) the servo output is likely to go to maximum and result in no motion drawing large currents and possibly causing damage.  For this reason you should be sure to set the Max Output to a small number to limit the current to a small value until you are certain everything is working correctly.  I suspect that is how you damaged that one motor.  4PH output operates in current mode where 1023 is full 35Amps of current.  So for example to limit the current to 2 Amps set Max Output to:

2/35 x 1023 = 58

The next step is to configure the commutation.  This involves the invDistPerCycle and the CommutationOffset.  invDistPerCycle tells how far in distance the encoder indicates for each motor commutation cycle.  So for example if your motor is a standard 200 full step per rev motor (50 motor poles) and your encoder is 4000 quadrature counts/rev then

ch0->invDistPerCycle=50.0/4000.0;

The CommutationOffset shifts the commutation to where the motor will have optimal torque based on the encoder position.  This must somehow be determined on each power up.  There are several possible techniques of doing this.  The simplest is to energize the motor as a stepper motor.  Assuming little or no load the stepper motor will align itself to a position where there is no torque (if there was any torque it would accelerate).  Knowing the position of zero torque we can know that the position of maximum torque is +/- 1/4 of a commutation cycle away.

At this point with commutation working you can start servo operation and tuning starting with some small P Gain.

Let me know how much of this makes sense and if you would like to pursue this.

Regards

TK

 

Thank you for the thorough reply!

Nothing in particular makes me think that this is a problem. I simply did not know if this is normal or not and I want to understand the system I am building. If it weren't normal, I would want to track it down.

I have used servos up to now and I guess I am spoiled by the quiet operation these things are capable of.

I got the stepper with the encoder back up and running. How do I configure kflop/snapamp to drive this as a  a 4 phase motor?

Well that only gives 20 encoder counts along a sine wave commutation cycle.  Not ideal sinusoidal commutaion.  Plus whatever belt slop there may be.  Somewhat marginal but it may work.

 

I would like to pursue this. I think putting up the information in the wiki is a good idea as well.

I have a US Digital E2 encoder with 500 CPR on a ball screw. I hooked it up to an encoder tester and it counts to 2000 over one rotation. This ballscrew is connected to a stepper via a timing belt, so that 1 motor rotation causes 1/2 ball screw rotation. Therefore, I effectively have a 250 CPR encoder on the stepper:



The stepper is a 3A rated 1.8 degree/step unit. So I plan to keep the current limit below that to be safe.

Ok, so start up as stepper:

    WriteSnapAmp(SNAP0+SNAP_PEAK_CUR_LIMIT0,9);  // current limit
    WriteSnapAmp(SNAP0+SNAP_PEAK_CUR_LIMIT1,9);  // current limit

    ch5->InputMode=NO_INPUT_MODE;
    ch5->OutputMode=MICROSTEP_MODE;
    ch5->Vel=200.000000;
    ch5->Accel=5000.000000;
    ch5->Jerk=50000.000000;
    ch5->P=1.000000;
    ch5->I=0.000000;
    ch5->D=0.000000;
    ch5->FFAccel=0.000000;
    ch5->FFVel=0.000000;
    ch5->MaxI=200.000000;
    ch5->MaxErr=1000000.000000;
    ch5->MaxOutput=200.000000;
    ch5->DeadBandGain=1.000000;
    ch5->DeadBandRange=0.000000;
    ch5->InputChan0=5;
    ch5->InputChan1=5;
    ch5->OutputChan0=10;
    ch5->OutputChan1=11;
    ch5->LimitSwitchOptions=0x0;
    ch5->InputGain0=1.000000;
    ch5->InputGain1=1.000000;
    ch5->InputOffset0=0.000000;
    ch5->InputOffset1=0.000000;
    ch5->invDistPerCycle=1.000000;
    ch5->Lead=0.000000;
    ch5->MaxFollowingError=1000000000.000000;
    ch5->StepperAmplitude=60.000000;
 
    ch5->iir[0].B0=1.000000;
    ch5->iir[0].B1=0.000000;
    ch5->iir[0].B2=0.000000;
    ch5->iir[0].A1=0.000000;
    ch5->iir[0].A2=0.000000;
 
    ch5->iir[1].B0=1.000000;
    ch5->iir[1].B1=0.000000;
    ch5->iir[1].B2=0.000000;
    ch5->iir[1].A1=0.000000;
    ch5->iir[1].A2=0.000000;
 
    ch5->iir[2].B0=1.000000;
    ch5->iir[2].B1=0.000000;
    ch5->iir[2].B2=0.000000;
    ch5->iir[2].A1=0.000000;
    ch5->iir[2].A2=0.000000;
     
     
    DefineCoordSystem(5,-1,-1,-1);
     
    EnableAxis(5);
// maybe sleep a little


Now reconfigure as 4 phase servo I change the following parameters:

ch5->invDistPerCycle=50.0/1000.0;
ch5->InputMode=ENCODER_MODE;
ch5->OutputMode=BRUSHLESS_4PH_MODE;

ch5->InputChan0=0;  // using encoder 0 input on kflop.

Does this seem right?

---In DynoMotion@yahoogroups.com, <tk@...> wrote :

Driving a Stepper as a 4 Phase Brushless motor is not common and is somewhat complicated.  it is basically as complex as a 3 Phase Brushless motor as Commutation and Tuning are required.  The commutation is more critical as there are many times more motor poles.  Tuning is more difficult as there is usually more torque ripple, cogging, inductance, etc... than with a servo motor.  The result is usually better than a Stepper Drive but not as good as a Servo.  So I usually recommend going to a servo motor if your goal is for performance.

But if you want to try it we can help.  It would be great to document on the wiki the performance you get driving as a Stepper compared with driving as a Servo.

If anything is configured wrong (ie commutation) the servo output is likely to go to maximum and result in no motion drawing large currents and possibly causing damage.  For this reason you should be sure to set the Max Output to a small number to limit the current to a small value until you are certain everything is working correctly.  I suspect that is how you damaged that one motor.  4PH output operates in current mode where 1023 is full 35Amps of current.  So for example to limit the current to 2 Amps set Max Output to:

2/35 x 1023 = 58

The next step is to configure the commutation.  This involves the invDistPerCycle and the CommutationOffset.  invDistPerCycle tells how far in distance the encoder indicates for each motor commutation cycle.  So for example if your motor is a standard 200 full step per rev motor (50 motor poles) and your encoder is 4000 quadrature counts/rev then

ch0->invDistPerCycle=50.0/4000.0;

The CommutationOffset shifts the commutation to where the motor will have optimal torque based on the encoder position.  This must somehow be determined on each power up.  There are several possible techniques of doing this.  The simplest is to energize the motor as a stepper motor.  Assuming little or no load the stepper motor will align itself to a position where there is no torque (if there was any torque it would accelerate).  Knowing the position of zero torque we can know that the position of maximum torque is +/- 1/4 of a commutation cycle away.

At this point with commutation working you can start servo operation and tuning starting with some small P Gain.

Let me know how much of this makes sense and if you would like to pursue this.

Regards

TK

On 10/10/2016 4:11 PM, homeloan@... [DynoMotion] wrote:

 

Thank you for the thorough reply!

Nothing in particular makes me think that this is a problem. I simply did not know if this is normal or not and I want to understand the system I am building. If it weren't normal, I would want to track it down.

I have used servos up to now and I guess I am spoiled by the quiet operation these things are capable of.

I got the stepper with the encoder back up and running. How do I configure kflop/snapamp to drive this as a  a 4 phase motor?

 

The only thing I see is that you are only energizing the motor as a stepper with 1 unit of current which is only 35ma of current.   This is probably not enough.  I'd try at least 30 units ~ 1 Amp

Otherwise after Enabling the Axis (or possibly even without the EnableAxis in C Code) you might do a small Move on the Step Response Screen.  This will allow us to see what is happening.  What you should see if the commutation is correct is the Error should increase which will cause the Output to increase, which should cause motion in the correct direction to reduce the error.

You also might try shifting the CommutationOffset by different amounts.  You only have 20 encoder counts over the cycle so there are really only 20 possibilities to choose from (multiples of 20 will all behave the same).  Being off by 1 or 2 probably should still work.  Also usually you can tell if the commutation is completely off or not.  That reduces the possibilities.  Once you get something that somewhat works you can gradually adjust the CommutationOffset to get the best result.

 

Awesome!

Here is what I have so far:

- I got the stepper connected and ran the program to configure it as a regular stepper. That works fine, and I can have it turn in KmotionCNC
- encoder channel zero counts correctly as the motor is turning.

- Then I added the following lines to the end of that program:


    DisableAxis(5);  // make sure the axis is disabled and not writing to SnapAmp
    ch5->InputMode=ENCODER_MODE;
    ch5->OutputMode=BRUSHLESS_4PH_MODE;
    Write4PH(ch5,1.0, 0.0);      // energize a pole
    Delay_sec(2.0);          // wait 
    ch5->CommutationOffset = +1.0 * 1000.0/50.0 * 0.25;
    ch5->invDistPerCycle= +1.0 * 1000.0/50.0;
    Zero(5);
    EnableAxisDest(5, 0.0);

The behavior I see now can best be described as if the stepper motor were not connected, but it had stronger magnets. I can force the axis out of its position with my hand, but it just jumps to another detent, not back to the zero position.

I did vary the two +1.0 parameters to the 4 possible positive/negative combinations with no effect at all.

ideas?

step_response_p1.0-13830.txt
step_response_p0.1-13830.txt

Yes there is no motion.  You only did a "step" of size 10.  So that creates an error of 10.  With a Gain of 1 that only puts 10 at the Output or 350ma to a coil as you can see on the current plots.  Apparently that isn't enough to move the motor.  Or the commutation is wrong and the the current just goes to holding the current position.  Increase the Step Size to 100.  That should provide 3.5Amps and be definitely enough to move if the commutation is energizing the correct coil.  Did you try different CommutationOffsets?  Did any of them create motion?

Regards

TK

 

I tried varying the commutation offset from 1-20 for both positive and negative values of invdistpercycle. There are some values where the axis is much harder to move than others, but other than that there is no change.

I did some moves as well as step responses on the axis, but there seems to movement on the encoder in response. I am attaching step response data for p=0.1 and p=1.0

Seems to make no difference in response whether I use EnableAxisDest or not.

Code used:
    DefineCoordSystem(5,-1,-1,-1); //define ch4 as x and ch5 as y; z and a disabled
    DisableAxis(5);  // make sure the axis is disabled and not writing to SnapAmp
    Write4PH(ch5,60.0, 0.0);      // energize a pole
    Delay_sec(2.0);          // wait 
    Zero(5);
    ch5->InputMode=ENCODER_MODE;
    ch5->OutputMode=BRUSHLESS_4PH_MODE;
    ch5->CommutationOffset = 12;
    ch5->invDistPerCycle= 1.0 * 1000.0/50.0;
    EnableAxisDest(5, 0.0);

step_response_p1.0_step200-13833.txt
step_response_p1.0_step100-13833.txt
step_response_p1.0_move200-13833.txt

I believe you are seeing SnapAmp Peak Current Fault occurring at the higher currents.  When this happens the Outputs switch off for about 1/2 seconds and then are automatically re-enabled.  You should see the Peak Current Limit LED on SnapAmp Flash for about 1/2 sec.  Let's just limit the current to 100 units for now.  You should have the Max Output set to around 100 as well.

BTW when plotting currents only select Current A and Current B for the two Stepper Coils A and B.  The other options are only for 3 phase modes.

I think the Step 100 (I prefer Move 100) shows the expected 3.5 Amps going to Coil B.  I don't understand why there is not any Encoder Motion.

As I explained before there is a possibility that applying current to a coil might just make the motor just hold its current position.  But then applying the current to the other coil should definitively cause the motor to move at least a Full Step of 1/200th of a rev or 5 encoder counts. 

Please make another plot with some CommutationOffset that causes Coil A to energize and observe if the encoder moves or not.

If it doesn't move then there must be something wrong with your wiring or configuration.  I assumed you already drove this motor/encoder in open loop Microstep mode to verify all the motor and encoder wiring and configuration is correct.  Have you done this?  Please post your latest Initialization file that you use to show the Coil A Current ramping up.

Regards

TK

 

I increased the step size to 100 and am attaching the result.
Something very interesting happens when the step size goes past about 150. This is easier to see in the move than in the step, so I am attaching a move as well as the step for a size of 200

I have tried offsets between -15 and +15 in 5 unit increments, for positive and negative values of the invdistpercyle and see no difference in the response graph. Two of the 3 channels are monotonically increasing, and decreasing respectively, until about a commanded distance of 150. Then current goes to zero. No movement on the motor.
Is it possible I have connected it wrong?
SnapAmp Connectors

			SnapAmp Connectors SnapAmp - Connector Pinouts   SnapAmp contains three connectors labeled JP1, JP6, and JP7.    JP6 - KMotion Communication & Logic Power
			View on www.dynomotion.com	Preview by Yahoo

 

does not mention the 4 phase setup, but it's still a stepper, so I assume the connection should be ok....

move100-13850.txt

Strange.  Are you aware that when pushing the Move button on the Step Response Screen all the settings for that Axis are downloaded to KFLOP including the invDistPerCycle?

Regards

TK

 

Just to make sure wiring and stepper configuration are still ok, I ran the stepper on this configuration:
     
    WriteSnapAmp(SNAP0+SNAP_PEAK_CUR_LIMIT0,9);  // current limit
    WriteSnapAmp(SNAP0+SNAP_PEAK_CUR_LIMIT1,9);  // current limit
    Delay_sec(0.1);  // wait for any fault to clear
 
    ch5->InputMode=NO_INPUT_MODE;
    ch5->OutputMode=MICROSTEP_MODE;
    ch5->Vel=200.000000;
    ch5->Accel=5000.000000;
    ch5->Jerk=50000.000000;
    ch5->P=0.100000;
    ch5->I=0.000000;
    ch5->D=0.000000;
    ch5->FFAccel=0.000000;
    ch5->FFVel=0.000000;
    ch5->MaxI=200.000000;
    ch5->MaxErr=1000000.000000;
    ch5->MaxOutput=100.000000;
    ch5->DeadBandGain=1.000000;
    ch5->DeadBandRange=0.000000;
    ch5->InputChan0=0;
    ch5->InputChan1=5;
    ch5->OutputChan0=10;
    ch5->OutputChan1=11;
    ch5->LimitSwitchOptions=0x0;
    ch5->InputGain0=1.000000;
    ch5->InputGain1=1.000000;
    ch5->InputOffset0=0.000000;
    ch5->InputOffset1=0.000000;
    ch5->invDistPerCycle=1.000000;
    ch5->Lead=0.000000;
    ch5->MaxFollowingError=1000000000.000000;
    ch5->StepperAmplitude=40.000000;
 
    ch5->iir[0].B0=1.000000;
    ch5->iir[0].B1=0.000000;
    ch5->iir[0].B2=0.000000;
    ch5->iir[0].A1=0.000000;
    ch5->iir[0].A2=0.000000;
 
    ch5->iir[1].B0=1.000000;
    ch5->iir[1].B1=0.000000;
    ch5->iir[1].B2=0.000000;
    ch5->iir[1].A1=0.000000;
    ch5->iir[1].A2=0.000000;
 
    ch5->iir[2].B0=1.000000;
    ch5->iir[2].B1=0.000000;
    ch5->iir[2].B2=0.000000;
    ch5->iir[2].A1=0.000000;
    ch5->iir[2].A2=0.000000;
     
     
    DefineCoordSystem(5,-1,-1,-1); //define ch4 as x and ch5 as y; z and a disabled
    EnableAxis(5);


Result: Motor can be turned in both directions using KmotionCNC. The encoder counts as it should

Then I changed the end of the program as follows:

    //EnableAxis(5);
    DisableAxis(5);  // make sure the axis is disabled and not writing to SnapAmp
    Write4PH(ch5,60.0, 0.0);      // energize a pole
    Delay_sec(2.0);          // wait 
    Zero(5);
    ch5->InputMode=ENCODER_MODE;
    ch5->OutputMode=BRUSHLESS_4PH_MODE;
    ch5->CommutationOffset = 5;
    ch5->invDistPerCycle= -1.0 * 50.0/1000.0;
    EnableAxisDest(5, 0.0);
   
Then did a move response on the following commutation offsets: -15,-10,-5,0,5,10,15.
I did this for both positive and negative values of invDistPerCycle.
The result is as if the commutation offset is ignored. Only one coil gets any current. However, as I am writing this, it occurs to me that the invdistpercycle is probably wrong and should be:
    ch5->invDistPerCycle= -1.0 * 1000.0/50.0;

So I made the following change:

    //EnableAxis(5);
    DisableAxis(5);  // make sure the axis is disabled and not writing to SnapAmp
    Write4PH(ch5,60.0, 0.0);      // energize a pole
    Delay_sec(2.0);          // wait 
    Zero(5);
    ch5->InputMode=ENCODER_MODE;
    ch5->OutputMode=BRUSHLESS_4PH_MODE;
    ch5->CommutationOffset = 5;
    ch5->invDistPerCycle= -1.0 * 50.0/1000.0;
    EnableAxisDest(5, 0.0);

Where again, I am going through all the above commutation offsets (and a few more). The result is largely unchanged but the motor now vibrates a bit in some of the moves - Data attached.

ok that's progress.  You might "Upload" settings from KFLOP to sync all the screen settings with those set by running your C Program.

Could you describe in more detail how it "hunts back and gets stuck"?

If it applies proper torque for some distance and then torque drops off and reverses (gets stuck) then something is wrong with the invDistPerCycle.  For example are you sure your encoder has 1000 counts and not 1024 counts?  Otherwise could you be loosing encoder counts?  Does it move back to Position=0 when you move it physically back to zero?  Or possibly the belt ratio or slop?

Regards

TK

 

I did not know that. So all the program adjustments for invdistpercycle were meaningless for the experiments.

Now we are getting somewhere. I am attaching a move response. I did experiment with different commutation offsets, but 5 works the best.

When forcing the axis away from its setpoint, it does hunt back as one would expect, but it pretty quickly gets stuck somewhere at maximum allowed current, in a situation like what you described in an earlier response.

---In DynoMotion@yahoogroups.com, <tk@...> wrote :

Strange.  Are you aware that when pushing the Move button on the Step Response Screen all the settings for that Axis are downloaded to KFLOP including the invDistPerCycle?

Regards

TK

On 10/12/2016 4:56 PM, homeloan@... [DynoMotion] wrote:

 

Just to make sure wiring and stepper configuration are still ok, I ran the stepper on this configuration:
     
    WriteSnapAmp(SNAP0+SNAP_PEAK_CUR_LIMIT0,9);  // current limit
    WriteSnapAmp(SNAP0+SNAP_PEAK_CUR_LIMIT1,9);  // current limit
    Delay_sec(0.1);  // wait for any fault to clear
 
    ch5->InputMode=NO_INPUT_MODE;
    ch5->OutputMode=MICROSTEP_MODE;
    ch5->Vel=200.000000;
    ch5->Accel=5000.000000;
    ch5->Jerk=50000.000000;
    ch5->P=0.100000;
    ch5->I=0.000000;
    ch5->D=0.000000;
    ch5->FFAccel=0.000000;
    ch5->FFVel=0.000000;
    ch5->MaxI=200.000000;
    ch5->MaxErr=1000000.000000;
    ch5->MaxOutput=100.000000;
    ch5->DeadBandGain=1.000000;
    ch5->DeadBandRange=0.000000;
    ch5->InputChan0=0;
    ch5->InputChan1=5;
    ch5->OutputChan0=10;
    ch5->OutputChan1=11;
    ch5->LimitSwitchOptions=0x0;
    ch5->InputGain0=1.000000;
    ch5->InputGain1=1.000000;
    ch5->InputOffset0=0.000000;
    ch5->InputOffset1=0.000000;
    ch5->invDistPerCycle=1.000000;
    ch5->Lead=0.000000;
    ch5->MaxFollowingError=1000000000.000000;
    ch5->StepperAmplitude=40.000000;
 
    ch5->iir[0].B0=1.000000;
    ch5->iir[0].B1=0.000000;
    ch5->iir[0].B2=0.000000;
    ch5->iir[0].A1=0.000000;
    ch5->iir[0].A2=0.000000;
 
    ch5->iir[1].B0=1.000000;
    ch5->iir[1].B1=0.000000;
    ch5->iir[1].B2=0.000000;
    ch5->iir[1].A1=0.000000;
    ch5->iir[1].A2=0.000000;
 
    ch5->iir[2].B0=1.000000;
    ch5->iir[2].B1=0.000000;
    ch5->iir[2].B2=0.000000;
    ch5->iir[2].A1=0.000000;
    ch5->iir[2].A2=0.000000;
     
     
    DefineCoordSystem(5,-1,-1,-1); //define ch4 as x and ch5 as y; z and a disabled
    EnableAxis(5);


Result: Motor can be turned in both directions using KmotionCNC. The encoder counts as it should

Then I changed the end of the program as follows:

    //EnableAxis(5);
    DisableAxis(5);  // make sure the axis is disabled and not writing to SnapAmp
    Write4PH(ch5,60.0, 0.0);      // energize a pole
    Delay_sec(2.0);          // wait 
    Zero(5);
    ch5->InputMode=ENCODER_MODE;
    ch5->OutputMode=BRUSHLESS_4PH_MODE;
    ch5->CommutationOffset = 5;
    ch5->invDistPerCycle= -1.0 * 50.0/1000.0;
    EnableAxisDest(5, 0.0);
   
Then did a move response on the following commutation offsets: -15,-10,-5,0,5,10,15.
I did this for both positive and negative values of invDistPerCycle.
The result is as if the commutation offset is ignored. Only one coil gets any current. However, as I am writing this, it occurs to me that the invdistpercycle is probably wrong and should be:
    ch5->invDistPerCycle= -1.0 * 1000.0/50.0;

So I made the following change:

    //EnableAxis(5);
    DisableAxis(5);  // make sure the axis is disabled and not writing to SnapAmp
    Write4PH(ch5,60.0, 0.0);      // energize a pole
    Delay_sec(2.0);          // wait 
    Zero(5);
    ch5->InputMode=ENCODER_MODE;
    ch5->OutputMode=BRUSHLESS_4PH_MODE;
    ch5->CommutationOffset = 5;
    ch5->invDistPerCycle= -1.0 * 50.0/1000.0;
    EnableAxisDest(5, 0.0);

Where again, I am going through all the above commutation offsets (and a few more). The result is largely unchanged but the motor now vibrates a bit in some of the moves - Data attached.

works-13878.txt

Interesting.  I think all your analysis is correct.

Seems like the commutation is significantly off after the move of 100 (0.1rev) as it sits still with about 1Amp of motor current.

What about after like 20 motor revs?  Does it still work?

It should be possible to use fractional counts as CommutationOffset.  ie 5.5 if that helps a little.

It isn't clear how much effort you put into servo tuning.

But anyway I certainly agree a higher resolution directly coupled encoder would be the way to go.

Regards

TK

 

Ok, it works. I am attaching data, FYI

It is still very 'jumpy', as if it has a lot of torque ripple. There is a big difference between commutation offsets 4,5,6 and so if the belt stretches even minutely, torque suffers.

Anyway, I can get it back to the stuck position, but as you suspected, it looks like it lost encoder counts when that happens. Most of the time it acts like you said. It will let me torque it away from equilibrium and it will return. If I overdo it, it oscillates back and forth rapidly.

Lessons learned:
- A single encoder count makes a lot of commutation angle difference in this setup. Go with high encoder counts if you want to run a stepper as a 4 phase motor!
- Additionally, belt flex can exacerbate the problem. Put the feedback device on the motor shaft!

I am going to have to order a stepper motor with high-res encoder mounted on the shaft to continue this experiment.

In addition, this gives me some answers to the original question of this topic. It looks like a feedback device (encoder) used to assist with the commutation of the motor should be connected as directly as possible to the motor axis. This serves to take any sort of drive train flex and machine vibration out of the feedback loop.

So for a stepper, the glass scale can be the sole feedback (though with fairly low gain). But if I put a servo motor on the ballscrew, there should be two encoders - one for the motor axis, and the glass scale.
Is that right?

move600-13881.txt
move400-13881.txt
after reinitialization-13881.txt

It seems to behave like your invDistPerCycle is slightly incorrect.  I asked you to verify that before but I don't recall if you responded.

It looks like after moving ~300 counts the commutation has gradually shifted to the point where torque is no longer created.  I believe that would be 1/4 cycle off or 5 counts.  So that comes out to:

5/300 = 1.6%

Like I said before if the encoder is doing 1024 counts/rev instead of you expected 1000 counts/rev that would be in that ball park.

You might try experimenting by adding a factor of 1.02 (or 0.98) to see if it get better.

Otherwise maybe it is loosing or gaining 2% of the encoder counts due to noise?

Regards

TK

 

Those are interesting questions. I did those experiments right now.

- First, even after energizing a pole and waiting 2 seconds and then zeroing the axis, the axis often winds up with an encoder count or two. After reinitializing once or twice without moving, the count does end up at 0, though.

- The motor does not make it through a whole rotation. It gets stuck somewhere. I am attaching traces of two moves. One 400 steps, the other 600. The motor can move up to a certain position, but no further. It does move back to the initial position on the move back, though.

- This extent of the movement limitation is not constant. After a complete reinitialization, I did another move that was limited even more than the previous case.

Not sure what I am seeing....:/

I put very little time into tuning. Trying to understand the system and its tradeoffs at this point, not optimize :)

---In DynoMotion@yahoogroups.com, <tk@...> wrote :

Interesting.  I think all your analysis is correct.

Seems like the commutation is significantly off after the move of 100 (0.1rev) as it sits still with about 1Amp of motor current.

What about after like 20 motor revs?  Does it still work?

It should be possible to use fractional counts as CommutationOffset.  ie 5.5 if that helps a little.

It isn't clear how much effort you put into servo tuning.

But anyway I certainly agree a higher resolution directly coupled encoder would be the way to go.

Regards

TK

On 10/13/2016 6:01 PM, homeloan@... [DynoMotion] wrote:

 

Ok, it works. I am attaching data, FYI

It is still very 'jumpy', as if it has a lot of torque ripple. There is a big difference between commutation offsets 4,5,6 and so if the belt stretches even minutely, torque suffers.

Anyway, I can get it back to the stuck position, but as you suspected, it looks like it lost encoder counts when that happens. Most of the time it acts like you said. It will let me torque it away from equilibrium and it will return. If I overdo it, it oscillates back and forth rapidly.

Lessons learned:
- A single encoder count makes a lot of commutation angle difference in this setup. Go with high encoder counts if you want to run a stepper as a 4 phase motor!
- Additionally, belt flex can exacerbate the problem. Put the feedback device on the motor shaft!

I am going to have to order a stepper motor with high-res encoder mounted on the shaft to continue this experiment.

In addition, this gives me some answers to the original question of this topic. It looks like a feedback device (encoder) used to assist with the commutation of the motor should be connected as directly as possible to the motor axis. This serves to take any sort of drive train flex and machine vibration out of the feedback loop.

So for a stepper, the glass scale can be the sole feedback (though with fairly low gain). But if I put a servo motor on the ballscrew, there should be two encoders - one for the motor axis, and the glass scale.
Is that right?

Hi,

I'm at a loss of why the commutation runs out if the encoder is working correctly.  I assume that is a timing belt.  I wouldn't think the belt has enough slop to cause that much commutaion problem.

 

I made a mark on the axis and rotated 10 times and got very close to 10000 counts. That actally surprised me, because that means the 2:1 pulley system works better than I anticipated.

I am going to get a dual shaft stepper and an encoder to fit the lathe. That will take the belt out of the equation.

You wanted to get some sort of performance comparison between servo and stepper motors, so I would like some input on motor selection. I do have a parker servo motor that approximates the stepper I have been using for these experiments and is of the same nema23 mount (pic attached). But while I am at it, I would prefer getting a larger (longer, still nema23) stepper.

I am also attaching a picture of the system it is going on to, just in case it matters.

Well I agree the cable is pretty short.  But SnapAmp generates noise, the cable is exposed, single ended, un-shielded, un-terminated, and I can't think of any other reason what the Commutation would drift off.  You might run your many revs test in Stepper Mode to see if the encoder still counts properly.  Or wait for the new motor/encoder :)

Yes Steppers are usually limited to ~ 1000 RPM Max and Servos might go to 3000RPM so swapping them in/out doesn't usually make sense without other mechanical changes.  I assumed you were set on buying a Stepper and was just suggesting to check its max speed before purchasing it.

Regards

TK

 

Yes, that is a timing belt. And it is tensioned very tight.

Currently negotiating for a 5000 line encoder with differential outputs to mount on a 1/4 shaft. With quadrature, that gives 20000 counts. That will provide some answers.

Those cables are super short. Would you really expect them to be shielded? That is quite difficult to do, considering that all the signals are coming from IDC connectors.

All the encoders that I am planning to use on the actual machine are differential. I spent a lot of time trying to figure out how to connect them to the SnapAmp and maintain shielding. My current plan is to lay out a small circuit board that has the shielded connectors I need on one side and a 50 pin IDC on the other. Then keep the ribbon cable as short as I can. Still not ideal, but with differential signals it's probably ok...

On the motor selection: Isn't one thing that distinguishes servo motors from steppers that steppers are inherently high torque slow speed devices (high voltage constant) and servo motors low torque high speed (low voltage constant)? Are you suggesting I try to find a servo motor with a voltage/torque constant similar to a stepper?

---In DynoMotion@yahoogroups.com, <tk@...> wrote :

Hi,

I'm at a loss of why the commutation runs out if the encoder is working correctly.  I assume that is a timing belt.  I wouldn't think the belt has enough slop to cause that much commutaion problem.

I do see that your encoder is single ended and unshielded.  It might only loose counts when the motors are energized and the noise level is higher.

Regarding motor selection:  The main thing is to look at the torque curves.  High torque motors tend to be very slow.

Regards
TK

On 10/14/2016 8:09 PM, homeloan@... [DynoMotion] wrote:

 

I made a mark on the axis and rotated 10 times and got very close to 10000 counts. That actally surprised me, because that means the 2:1 pulley system works better than I anticipated.

I am going to get a dual shaft stepper and an encoder to fit the lathe. That will take the belt out of the equation.

You wanted to get some sort of performance comparison between servo and stepper motors, so I would like some input on motor selection. I do have a parker servo motor that approximates the stepper I have been using for these experiments and is of the same nema23 mount (pic attached). But while I am at it, I would prefer getting a larger (longer, still nema23) stepper.

I am also attaching a picture of the system it is going on to, just in case it matters.

step-13992.txt
move-13992.txt

It looks pretty nasty. 

So this is 4 phase brushless correct?   Encoder mounted to motor shaft?

The Commutation is verified to work properly? (ie you can move 100 motor revs and the performance doesn't change)

 

Ok, I finally got the encoder and new motor in. 5000 lines per revolution. Everything checks out ok in principle.  The motor is not mounted yet, so rapid movements cause crazy oscillations, but you mentioned that before.

Anyway, I am attaching both a move and a step for a small movement. I have done larger, slow movements, and they seem to work as well. I think one can clearly see the torque ripple between individual steps in the position. Is that expected? At rest, there is a little vibration - but its generally less than +- 5 encoder counts.

I would like some directions as to what to do from here. Should I run any more tests/tuning before mounting? What can I do that is helpful to add to the wiki?

Ok thanks for that.

Velocity is set crazy slow (10/20000/60 = 0.000008 RPM)

I don't understand why moving fast would "get stuck and vibrate".  If the commutation is working correctly it shouldn't ever get stuck.  A large error should simply give max torque in one direction.  If the encoder counts are lost the commutation would go wrong and likely get stuck.  You might run a test to see if the encoder position has drifted after attempting to move fast.  You should probably figure out what is happening before going forward.

Otherwise I'd suggest Tuning:

#1 add a 2nd order Low Pass filter at 1000Hz Q=1.4 in the 3rd Filter position to smooth out output spikes that will be caused by D gain taking the derivative of the Encoder (which consists of integer steps).

#2 add/increase D gain to a point where the system goes unstable, then back off like 30%

#3 see if P gain can then be increased

#4 You might also try tweaking the Commutation offset by a few counts to see if performance can be improved.

HTH

Regards

TK

 

Yes, this is configured as 4 phase brushless. The encoder is mounted directly to the shaft.
The motor can do 100 revs, but in order to do that I had to configure the velocity parameter down quite a bit. Otherwise the motor would get stuck and vibrate - I guess because of the proportional gain.

Here is the complete configuration:

#include "KMotionDef.h"
 
// Configure SnapAMP for 2 stepper motors in Optical Table Lathe
 
void main() 
{
     
    WriteSnapAmp(SNAP0+SNAP_PEAK_CUR_LIMIT0,9);  // current limit
    WriteSnapAmp(SNAP0+SNAP_PEAK_CUR_LIMIT1,9);  // current limit
    Delay_sec(0.1);  // wait for any fault to clear
 
    ch5->InputMode=NO_INPUT_MODE;
    ch5->OutputMode=MICROSTEP_MODE;
    ch5->Vel=10.000000;
    ch5->Accel=100.000000;
    ch5->Jerk=1000.000000;
    ch5->P=0.100000;
    ch5->I=0.000000;
    ch5->D=0.000000;
    ch5->FFAccel=0.000000;
    ch5->FFVel=0.000000;
    ch5->MaxI=200.000000;
    ch5->MaxErr=1000000.000000;
    ch5->MaxOutput=100.000000;
    ch5->DeadBandGain=1.000000;
    ch5->DeadBandRange=0.000000;
    ch5->InputChan0=8;
    ch5->InputChan1=9;
    ch5->OutputChan0=10;
    ch5->OutputChan1=11;
    ch5->LimitSwitchOptions=0x0;
    ch5->InputGain0=1.000000;
    ch5->InputGain1=1.000000;
    ch5->InputOffset0=0.000000;
    ch5->InputOffset1=0.000000;
    ch5->invDistPerCycle=1.000000;
    ch5->Lead=0.000000;
    ch5->MaxFollowingError=1000000000.000000;
    ch5->StepperAmplitude=40.000000;
 
    ch5->iir[0].B0=1.000000;
    ch5->iir[0].B1=0.000000;
    ch5->iir[0].B2=0.000000;
    ch5->iir[0].A1=0.000000;
    ch5->iir[0].A2=0.000000;
 
    ch5->iir[1].B0=1.000000;
    ch5->iir[1].B1=0.000000;
    ch5->iir[1].B2=0.000000;
    ch5->iir[1].A1=0.000000;
    ch5->iir[1].A2=0.000000;
 
    ch5->iir[2].B0=1.000000;
    ch5->iir[2].B1=0.000000;
    ch5->iir[2].B2=0.000000;
    ch5->iir[2].A1=0.000000;
    ch5->iir[2].A2=0.000000;
     
     
    DefineCoordSystem(5,-1,-1,-1); //define ch4 as x and ch5 as y; z and a disabled
    DisableAxis(5);
    
    Write4PH(ch5,80.0, 0.0);      // energize a pole
    Delay_sec(4.0);          // wait 


    Zero(5);
       ch5->InputMode=ENCODER_MODE;
    ch5->OutputMode=BRUSHLESS_4PH_MODE;
    ch5->CommutationOffset = 0.25 * 20000/50;  // offset ~1/4 of encoder count per pole 
    ch5->invDistPerCycle= 1.0 * 50.0/20000.0;  // 200 step stepper -> 50 poles; 5000 line encoder -> 20000 counts per revolution.
    EnableAxisDest(5, 2000000.0);
    //Delay_sec(1.0);          // wait 
      //DisableAxis(5);  // make sure the axis is disabled and not writing to SnapAmp
}


---In DynoMotion@yahoogroups.com, <tk@...> wrote :

It looks pretty nasty. 

So this is 4 phase brushless correct?   Encoder mounted to motor shaft?

The Commutation is verified to work properly? (ie you can move 100 motor revs and the performance doesn't change)

It might just require better tuning.  This is a torque servo and will be theoretically unstable with just P gain.

What are all your settings?

Regards
TK

On 11/5/2016 5:42 PM, homeloan@... [DynoMotion] wrote:

 

Ok, I finally got the encoder and new motor in. 5000 lines per revolution. Everything checks out ok in principle.  The motor is not mounted yet, so rapid movements cause crazy oscillations, but you mentioned that before.

Anyway, I am attaching both a move and a step for a small movement. I have done larger, slow movements, and they seem to work as well. I think one can clearly see the torque ripple between individual steps in the position. Is that expected? At rest, there is a little vibration - but its generally less than +- 5 encoder counts.

I would like some directions as to what to do from here. Should I run any more tests/tuning before mounting? What can I do that is helpful to add to the wiki?

 

success-14003.txt

Strange.  I can't think of why repeating the phase finding would make any difference.  Each time the exact same pole is energized, the rotor should move to the exact same position, and the encoder should be zeroed at exactly the same manner.

But now that I said that one possibility comes to mind.  if your system has friction then the rotor may not align perfectly with the pole and be off one way or the other depending on where it was when it started.  Repeating the process (with some shocks between) might cause it to settle in on a more perfect rotor/pole alignment.

If your encoder has an index mark then this can be used as a more reliable way of phase finding.  This method requires rotating the motor on power up (as a stepping motor) to find the index mark.  Once the index mark is found then the rotor position is known and the encoder can be zeroed and the commutation offset be set to whatever works best.  Friction that causes the rotor position to lag behind the energized pole positions wont matter as long as the rotor moves.  It would cause a slight delay in when we find the index mark, but when it is found we will know the rotor position precisely.

It doesn't surprise me that the encoder position is off by tens of encoder counts after initializing because of your low gain of P=0.05.  That means that 20 encoder counts of error are required to change the output by 1 current unit.  So if there are a couple counts of current offset (or any other offsets) the position will be necessarily off by enough to compensate.  If you add the smallest amount of I gain the error should settle out about zero.

I don't normally like to do large step response tests.  In normal operation the errors should never be anywhere near 200000 counts.  More like 200 counts.  So it isn't really meaningful.  And as you see the Output goes into full saturation.  It is nice to know how the system responds to such huge errors if they were ever to somehow occur.  But I prefer to check how the motion follows a specified Velocity, Acceleration, and Jerk.

I calculate 0 to 1500 RPM in less than 1/2 seconds which seems good for a stepper motor.  I don't really understand why the deceleration rate is so much higher than the acceleration rate.  I suppose the inductance, back-emf, and resistance are all working against the acceleration.  The currents are quite low and much below the commanded output.

Great work.

Regards

TK

On 11/7/2016 6:56 PM, homeloan@... [DynoMotion] wrote:

 

Ok, after trying many things I finally have it working. I don't understand why it works, though, so I would appreciate an education:

I noticed that even though I did this:

    DisableAxis(5);    
    Write4PH(ch5,100,0);      // energize a pole
    Delay_sec(2);          // wait     
    Zero(5);
    ch5->InputMode=ENCODER_MODE;
    ch5->OutputMode=BRUSHLESS_4PH_MODE;
    ch5->CommutationOffset = 0.25 * 20000/50;  // offset ~1/4 of encoder count per pole 
    ch5->invDistPerCycle= 1.0 * 50.0/20000.0; 
    EnableAxisDest(5, 0.0);

The position counter in the axis window would generally not be zero. In fact, it was varying tens of counts. And the performance of the motor would depend on that number (anything from moving nicely to running away like a jet engine)

I found that executing the setup program several times back to back could get the count to zero, or at least single digit deviations.

I tried many things to get to a consistent number here. I tried to cycle the Write4PH trough a loop, increasing strength and or angle while doing so, and a lot of other stuff.
The one thing that finally got me consistent behavior is running above code 2 or 3 times. After doing that, the count generally hovers at about +10-11

That already lets the stepper work great. Though I found that adding +5 encoder counts gives me a more symmetrical behavior in the step response.

Why does this work, but manually phasing does not? Complete code:


#include "KMotionDef.h"
 
 
 
void main() 
{
     
    WriteSnapAmp(SNAP0+SNAP_PEAK_CUR_LIMIT0,9);  // current limit
    WriteSnapAmp(SNAP0+SNAP_PEAK_CUR_LIMIT1,9);  // current limit
    Delay_sec(0.1);  // wait for any fault to clear
 
    ch5->InputMode=NO_INPUT_MODE;
    ch5->OutputMode=MICROSTEP_MODE;
    ch5->Vel=20.000000;
    ch5->Accel=100.000000;
    ch5->Jerk=1000.000000;
    ch5->P=0.050000;
    ch5->I=0.000000;
    ch5->D=5.000000;
    ch5->FFAccel=0.000000;
    ch5->FFVel=0.000000;
    ch5->MaxI=200.000000;
    ch5->MaxErr=1000000.000000;
    ch5->MaxOutput=200.000000;
    ch5->DeadBandGain=1.000000;
    ch5->DeadBandRange=0.000000;
    ch5->InputChan0=8;
    ch5->InputChan1=9;
    ch5->OutputChan0=10;
    ch5->OutputChan1=11;
    ch5->LimitSwitchOptions=0x0;
    ch5->InputGain0=1.000000;
    ch5->InputGain1=1.000000;
    ch5->InputOffset0=0.000000;
    ch5->InputOffset1=0.000000;
    ch5->invDistPerCycle=1.000000;
    ch5->Lead=0.000000;
    ch5->MaxFollowingError=1000000000.000000;
    ch5->StepperAmplitude=40.000000;
 
    ch5->iir[0].B0=1.000000;
    ch5->iir[0].B1=0.000000;
    ch5->iir[0].B2=0.000000;
    ch5->iir[0].A1=0.000000;
    ch5->iir[0].A2=0.000000;
 
    ch5->iir[1].B0=1.000000;
    ch5->iir[1].B1=0.000000;
    ch5->iir[1].B2=0.000000;
    ch5->iir[1].A1=0.000000;
    ch5->iir[1].A2=0.000000;
 
    ch5->iir[2].B0=0.0566048;
    ch5->iir[2].B1=0.11321;
    ch5->iir[2].B2=0.0566048;
    ch5->iir[2].A1=1.22804;
    ch5->iir[2].A2=-0.454462;
 
 
     
    DefineCoordSystem(5,-1,-1,-1);
 
    DisableAxis(5);   
    Write4PH(ch5,100,0);      // energize a pole
    Delay_sec(2);          // wait     
    Zero(5);
    ch5->InputMode=ENCODER_MODE;
    ch5->OutputMode=BRUSHLESS_4PH_MODE;
    ch5->CommutationOffset = 0.25 * 20000/50;  // offset ~1/4 of encoder count per pole 
    ch5->invDistPerCycle= 1.0 * 50.0/20000.0;  // 200 step stepper -> 50 poles; 5000 line encoder -> 20000 counts per revolution.
    EnableAxisDest(5, 0.0);
 
    DisableAxis(5);    
    Write4PH(ch5,100,0);      // energize a pole
    Delay_sec(2);          // wait     
    Zero(5);
    ch5->InputMode=ENCODER_MODE;
    ch5->OutputMode=BRUSHLESS_4PH_MODE;
    ch5->CommutationOffset = 0.25 * 20000/50;  // offset ~1/4 of encoder count per pole 
    ch5->invDistPerCycle= 1.0 * 50.0/20000.0;  // 200 step stepper -> 50 poles; 5000 line encoder -> 20000 counts per revolution.
    EnableAxisDest(5, 0.0);
 
 
    DisableAxis(5);    
    Write4PH(ch5,100,0);      // energize a pole
    Delay_sec(2);          // wait     
    Zero(5);
    ch5->InputMode=ENCODER_MODE;
    ch5->OutputMode=BRUSHLESS_4PH_MODE;
    ch5->CommutationOffset = 0.25 * 20000/50 +3;  // offset ~1/4 of encoder count per pole 
    ch5->invDistPerCycle= 1.0 * 50.0/20000.0;  // 200 step stepper -> 50 poles; 5000 line encoder -> 20000 counts per revolution.
    EnableAxisDest(5, 0.0);
    Delay_sec(1.0);          // wait 
    float position = ch5->Position; // save position
    Delay_sec(0.10);          // wait 
    position += ch5->Position; // save position
    Delay_sec(0.10);          // wait
    position += ch5->Position; // save position
    Delay_sec(0.10);          // wait
    position += ch5->Position; // save position
    Delay_sec(0.10);          // wait
    printf("position: %f \n",position/4);
}



---In DynoMotion@yahoogroups.com, <homeloan@...> wrote :

It actually moves much faster than that. A revolution about every second or two. I did put a mark on the shaft before the 100 rotations. No lost steps as far as I can tell.

---In DynoMotion@yahoogroups.com, <tk@...> wrote :

Ok thanks for that.

Velocity is set crazy slow (10/20000/60 = 0.000008 RPM)

I don't understand why moving fast would "get stuck and vibrate".  If the commutation is working correctly it shouldn't ever get stuck.  A large error should simply give max torque in one direction.  If the encoder counts are lost the commutation would go wrong and likely get stuck.  You might run a test to see if the encoder position has drifted after attempting to move fast.  You should probably figure out what is happening before going forward.

Otherwise I'd suggest Tuning:

#1 add a 2nd order Low Pass filter at 1000Hz Q=1.4 in the 3rd Filter position to smooth out output spikes that will be caused by D gain taking the derivative of the Encoder (which consists of integer steps).

#2 add/increase D gain to a point where the system goes unstable, then back off like 30%

#3 see if P gain can then be increased

#4 You might also try tweaking the Commutation offset by a few counts to see if performance can be improved.

HTH

Regards

TK

On 11/5/2016 7:41 PM, homeloan@... [DynoMotion] wrote:

 

Yes, this is configured as 4 phase brushless. The encoder is mounted directly to the shaft.
The motor can do 100 revs, but in order to do that I had to configure the velocity parameter down quite a bit. Otherwise the motor would get stuck and vibrate - I guess because of the proportional gain.

Here is the complete configuration:

#include "KMotionDef.h"
 
// Configure SnapAMP for 2 stepper motors in Optical Table Lathe
 
void main() 
{
     
    WriteSnapAmp(SNAP0+SNAP_PEAK_CUR_LIMIT0,9);  // current limit
    WriteSnapAmp(SNAP0+SNAP_PEAK_CUR_LIMIT1,9);  // current limit
    Delay_sec(0.1);  // wait for any fault to clear
 
    ch5->InputMode=NO_INPUT_MODE;
    ch5->OutputMode=MICROSTEP_MODE;
    ch5->Vel=10.000000;
    ch5->Accel=100.000000;
    ch5->Jerk=1000.000000;
    ch5->P=0.100000;
    ch5->I=0.000000;
    ch5->D=0.000000;
    ch5->FFAccel=0.000000;
    ch5->FFVel=0.000000;
    ch5->MaxI=200.000000;
    ch5->MaxErr=1000000.000000;
    ch5->MaxOutput=100.000000;
    ch5->DeadBandGain=1.000000;
    ch5->DeadBandRange=0.000000;
    ch5->InputChan0=8;
    ch5->InputChan1=9;
    ch5->OutputChan0=10;
    ch5->OutputChan1=11;
    ch5->LimitSwitchOptions=0x0;
    ch5->InputGain0=1.000000;
    ch5->InputGain1=1.000000;
    ch5->InputOffset0=0.000000;
    ch5->InputOffset1=0.000000;
    ch5->invDistPerCycle=1.000000;
    ch5->Lead=0.000000;
    ch5->MaxFollowingError=1000000000.000000;
    ch5->StepperAmplitude=40.000000;
 
    ch5->iir[0].B0=1.000000;
    ch5->iir[0].B1=0.000000;
    ch5->iir[0].B2=0.000000;
    ch5->iir[0].A1=0.000000;
    ch5->iir[0].A2=0.000000;
 
    ch5->iir[1].B0=1.000000;
    ch5->iir[1].B1=0.000000;
    ch5->iir[1].B2=0.000000;
    ch5->iir[1].A1=0.000000;
    ch5->iir[1].A2=0.000000;
 
    ch5->iir[2].B0=1.000000;
    ch5->iir[2].B1=0.000000;
    ch5->iir[2].B2=0.000000;
    ch5->iir[2].A1=0.000000;
    ch5->iir[2].A2=0.000000;
     
     
    DefineCoordSystem(5,-1,-1,-1); //define ch4 as x and ch5 as y; z and a disabled
    DisableAxis(5);
    
    Write4PH(ch5,80.0, 0.0);      // energize a pole
    Delay_sec(4.0);          // wait 


    Zero(5);
       ch5->InputMode=ENCODER_MODE;
    ch5->OutputMode=BRUSHLESS_4PH_MODE;
    ch5->CommutationOffset = 0.25 * 20000/50;  // offset ~1/4 of encoder count per pole 
    ch5->invDistPerCycle= 1.0 * 50.0/20000.0;  // 200 step stepper -> 50 poles; 5000 line encoder -> 20000 counts per revolution.
    EnableAxisDest(5, 2000000.0);
    //Delay_sec(1.0);          // wait 
      //DisableAxis(5);  // make sure the axis is disabled and not writing to SnapAmp
}


---In DynoMotion@yahoogroups.com, <tk@...> wrote :

It looks pretty nasty. 

So this is 4 phase brushless correct?   Encoder mounted to motor shaft?

The Commutation is verified to work properly? (ie you can move 100 motor revs and the performance doesn't change)

It might just require better tuning.  This is a torque servo and will be theoretically unstable with just P gain.

What are all your settings?

Regards
TK

On 11/5/2016 5:42 PM, homeloan@... [DynoMotion] wrote:

 

Ok, I finally got the encoder and new motor in. 5000 lines per revolution. Everything checks out ok in principle.  The motor is not mounted yet, so rapid movements cause crazy oscillations, but you mentioned that before.

Anyway, I am attaching both a move and a step for a small movement. I have done larger, slow movements, and they seem to work as well. I think one can clearly see the torque ripple between individual steps in the position. Is that expected? At rest, there is a little vibration - but its generally less than +- 5 encoder counts.

I would like some directions as to what to do from here. Should I run any more tests/tuning before mounting? What can I do that is helpful to add to the wiki?

 

 

Strange about requiring to repeat those steps.  Switching to 4 phase mode should have no effect until the axes is Enabled.  Enabling and immediately Disabling shouldn't do any output.  The Zero() function does change the commutation, but it is set properly again so that shouldn't have an effect.  So I'm at a loss of what is going on.  We could probably figure it out by adding delays and print statements to see exactly what ends up happening differently.

It would be nice to have a comparison of open loop steppers vs closed loop 4 phase brushless.   What speed/acceleration each is able to achieve.  An error plot for each at the same speed/acceleration.  Or maybe video/audio showing the difference in smoothness/sound.

 

Thank you for all that information!

Up to now the motor was not mounted to anything. So there was negligible friction. I did mount it to the axis it is meant for. That axis has a lot of friction. Results:

Nothing I tried removes the requirement to first energize a pole, then switch to 4 phase mode, then energize the pole again and switch back to 4 phase mode.

That being said, I was able to get the axis to work very well. It is whisper quiet now and I am happy with the performance. It acts like my 3phase servo motors.

I do understand about using the index pulse and have been considering it. However, I rather like not having the motor move very much on startup. Since it is connected to the shaft directly, a rotation is quite some movement and can easily hit the end stop or work piece.

Thank you very much for all the help! You mentioned some of this information maybe being useful in the wiki. If you can think of some specific things you would like there, please let me know.

I think I seen an issue.  Piecing together your code pieces it seems like the first time you "Zero()" the axis channel the Input Mode is not configured as Encoder Input.  This will still zero the axis position but because of how the hardware works (DSP tracks changes in an 8-bit hardware counter from the previous reading) if the axis is moved while the Encoder is not configured (which is different than disabled), then on the first time after it is configured there can be a jump in position of up to +/-128 counts.

 

I think it might be fruitful to hunt this down. Behavior that is not understood can be dangerous with CNC machines.

I just double checked one more time, and the problem is definitely there and I can make it happen at will. Let me know what printfs to send to the console and I will take care of it.

Steps, that will reproduce the problem/solution for me:

- disable axis
- pull hard on axis or any other means to turn the motor axis a little
- run program (without a second round of energizing)

Almost without fail, after the axis is enabled as a servo, the encoder count in the axis window will show a value other than 0 (destination 0), usually in the tens of counts, but in the latest test I had a value over 1700. Yes, it is holding steady at that value...until I try to send move commands.

When that happens, the servo performance is poor. Sometimes I had the (unmounted) servo runaway like a jet engine, sometimes the motor will not move at all.

If I double up on the phasing procedure, the encoder shows a non-zero value right after the first enabling of the axis, but after the second iteration is always (well, every test so far) 0 +-1, and the motor performs as expected.

Thoughts?

MAH06809-14055.m4v

Ha.  I love it.

A position error plot of both would be interesting.

Something like a circle would sweep through a range of speeds.

Regards

TK

 

OK, I started running some comparison tests between the stepper mode and servo mode. I am attaching a video that shows me running my cross slide simply in stepper mode, then changing over to servo mode and repeating the test. I know that they don't run at quite the same speed - that is because the units for the feedrate change between modes and I had to play around with it a little. Anyway,informal testing shows that the maximum speed, at least, seems to be the same in either case.

My thoughts:

- The servo and stepper modes should probably tuned and filtered to make them the best they can be before comparing
- The test I am running is probably not the best test. Maybe a series of moves at differing speeds?

Your thoughts?

Hi Jan.

Did you miss type and mean AX57-102 motor?

What radius circle are you running?

What do you mean by highest speed part of the circle?

What Velocity and Acceleration can you do using the Step Response Screen?

The Peak Current Limits are only approximate and intended to detect shorts and such.  The Peak current limit might be tripping and shutting down the outputs.  Does the Fault LED on SnapAmp Flash?

The limiting factor may be the motor inductance.  The AX57-102 has 74mH.  If I did the math correct:

The 125RPM = 417 full steps/sec = 0.0024 sec/step

The change in current for an ideal inductor is:

I = V T / L = 54V * 0.0024s / 0.074H = 1.75A

So this isn't even enough time to change a coil from +1A to -1A in the theoretical ideal case.

Regards

TK

 

Happy new Year!

I am working on making a video of running the circle and position error plot, and I have hit a snag.

I increased the feedrate until I got a following error. The maximum feedrate the axis still worked was F20 (inch/min). At F25, it will error out when it goes towards the highest speed part of the circle.

The motor is a A/AX-57-201 from Parker Compumotor. According to documentation here:
https://www.parkermotion.com/manuals/a-ax/AX_Chp6.pdf

So, to make a guesstimation from that data....

This motor has 0.85 Nm of torque and should be driven at 0.750A of current.

The motor torque constant K = torque/current = 0.85/0.75 = 1.13 newton-metres per ampere

The motor back emf constant = 30 / (Pi * motor torque constant) = 8.45 (radians/sec)/Volt = 80.69 RPM/Volt

So as a rough estimation I should be able to get 80 RPM/Volt from this motor as back emf. When unloaded, the 54V supply should yield a bit over 4000 RPM max speed.

The 25 inch/min feedrate that I am failing on amounts to 25*5 = 125 rotations/min. So I don't think I am limited by back emf. The current limit is set by WriteSnapAmp(SNAP0+SNAP_PEAK_CUR_LIMIT0,9); to about 2A, but the analog monitor in KMotion never even comes close to 1A. But if I am not current nor voltage limited, what could cause the following error? Did I screw up the calcuations?

Thanks,

Jan

---In DynoMotion@yahoogroups.com, <tk@...> wrote :

Ha.  I love it.

A position error plot of both would be interesting.

Something like a circle would sweep through a range of speeds.

Regards

TK

On 11/13/2016 8:17 PM, homeloan@... [DynoMotion] wrote:

 

OK, I started running some comparison tests between the stepper mode and servo mode. I am attaching a video that shows me running my cross slide simply in stepper mode, then changing over to servo mode and repeating the test. I know that they don't run at quite the same speed - that is because the units for the feedrate change between modes and I had to play around with it a little. Anyway,informal testing shows that the maximum speed, at least, seems to be the same in either case.

My thoughts:

- The servo and stepper modes should probably tuned and filtered to make them the best they can be before comparing
- The test I am running is probably not the best test. Maybe a series of moves at differing speeds?

Your thoughts?